In many network-based multimedia applications, data is sent from a first point to a second point in packets, which are then decoded when received at the second point, and played back on playback hardware. For example, in the case of streaming audio or video multicasting, a server sends to a number of clients over a network the packets of data that make up the desired audio or video, which are received at the clients, decoded, and played back. In another example, in a two- or multi-party video or audio conference, the parties send back and forth data packets over a network, which are then decoded at the receiving parties and played back. Such streaming applications are especially popular over the Internet, intranets, and extranets.
A difficulty with such applications, however, is that the transmittal and receipt of the data packets through the network may become hampered. Packets may be held up, or lost, for example, throughout the network. Or, the bandwidth at which a given party can receive or send packets may be limited. The practical effect of these problems is that the parties may find their audio and/or video streams broken up—that is, the resulting  multimedia stream when played may be choppy, such that the perceptual quality of the playback may be degraded.
A limited solution to this problem is to introduce a predetermined latency in the data stream, via a buffer or other mechanism. In this way, if packets are held up in the network, playback at the receiving end is not affected because other packets still may be stored in the buffer. This solution has some success in one-way multicast situations, where a server is transmitting data for playback on multiple clients. This is because the clients only receive data packets, and are not expected to send responsive data packets to the server or the other clients.
However, in other situations, introduction of a predetermined latency is less than optimal. For example, in the case of audio or video conferences, where communication is two-way among the parties of the conference, introduction of a predetermined latency may affect the quality of the conference, especially where the latency is larger than required. The parties may find, for example, that their ability to respond in a timely manner to parties is affected. That is, because the parties may assume that the conference is occurring in real-time, when in reality the conference is being buffered, it may be difficult for parties to interrupt another in a manner that resembles a normal, in-person conference.
For these and other reasons, there is a need for the present invention.